Complexity and shortcuts

Brena Zimmerman and Sholom Glouberman who are studying the science of complexity have said that there are three kinds of problems in the world: simple, complicated and complex ones:

• simple problems might be something similar with baking a cake where you have a recipe which you need to follow. Of course, you will have to learn a few basic techniques. But once you are mastering those and you follow the recipe there is a high probability of success.
• complicated problems could be something like sending a rocket to the moon. You don't have a straight forward recipe for it. Usually, a complicated problem can be composed of multiple simple problems. It will require multiple people, teams and specialized expertise who will need to time and coordinate properly. The success of it will depend on all these factors and is not unusual to have unanticipated difficulties.The advantage is that once you build that expertise and have the experience you can easier repeat the process and even improve it.
• complex problems could be something like raising a child. The major difficulty here is that every child is unique. Although raising one child will provide you experience it doesn't guarantee success with the next child. Expertise is valuable but for sure it will not be sufficient. Complex problems will usually have outcomes which are highly uncertain. That doesn't mean you can't still be successful.

In our day to day activities we are overwhelmed by the decisions we have to take. We have to decide on things like: what kind of bread should I eat? what book should I read next? what type of subscription should I chose for a service? what type of TV should I buy? to which school should I send my child? ... you got the idea. Our brain needs to find shortcuts in taking decisions. One problem which we might have with shortcuts is that they can lead to biases.
This is why taking decisions in today's dynamic environment is not something easy to do. Probably it was a little bit easier in the past. If we continue doing things in the same way, we can expect to achieve at maximum the same things as before. This is why we should start doing things differently.

Intuition or Data Driven products?

Technology domain is probably one of the most dynamic and complex environments. This is why building a software product usually involves a mixture of simple, complicated and complex problems. Decision on what exactly to build is usually in the hands of a Product Manager (Product Owner or in some cases can be a group of stakeholders) and the software team (or teams). They have to make decisions on problems of various level of difficulty. They have to decide on things like: should I build this feature? should I make this change request? should I fix this bug? should I implement this technical improvement? should I reduce technical debt here?

Based on how decisions are made when running a software product I would say we can observe 3 trends:

• intuition driven products
• data driven products
• mix of data and intuition driven products

Why the majority of products we build are mainly driven by intuition? Especially when we say we are agile and try to move and adapt faster to business needs, clients, customers and stakeholders...
The Product Manager and software team usually decide (the decision can be shared or driven by one side of the parties) what to do next based on their intuition, their experience, their knowledge and in some rare situations based on data. Taken into account that they are facing complex problems, how can they make valuable decisions? How can they have safer shortcuts which won't lead so easily to biases. Things gets worse if for example:

• Product Manager is driving the product by ignoring completely or partially stakeholders, clients and/or teams suggestions
• Product Manager is in a position to implement stakeholders and/or clients wishes without being able to decide.
• software team is focusing mainly on quality, technical improvements and reducing technical debt. Without paying to much attention to understanding clients and stakeholders needs.

Given the complexity of problems we face in running software products, can we blame anybody? We all need shortcuts and the simplest ones are based on intuition. But maybe, there can be a way of having both: data and intuition driven decisions which are still shortcuts, but more valuable...
My recommendation for better decisions and shortcuts is a 3 steps method which implies data and intuition:

1. use data to better define the problem you are trying to solve.
2. use intuition to come up with solution for the problem you identified. At this step you also need to define what you are going to measure for the solution you are going to implement.
3. after implementation, use data again to determine what have you learned with that solution.

Adding data in your decisions

Bellow I've listed some of the practices which I believe can help you to add the data element in your decisions.

Use Eric Ries Lean Startup Cycle

The major take away from Eric's methodology for me is his method of build-measure-learn. Everything you build should go through a cycle of building, measuring and learning. Once you decide to build something define also how you will measure your learning on what you build. This way you will able to say you are on the right track or you need to adapt.Anyhow, by measuring you are able to learn from it.

Do a lot of A/B testing using web analytics tools

There are many tools available (starting with google analytics) which provide great reports and data. Many companies mastered how to use them. The amount of stuff you can track is impressive.
I think these kind of tools need to go hand in hand with a change in how we deliver software and we make it available to the users. We should be able to deliver fast and rollback if necessary. Be able to easily toggle features on/off and to define rules to divert traffic to new functionality.
A/B testing tools are a powerful tools which can help Product Managers make and measure the impact of their decisions. What if when you are proposing a new marketing campaign you will be able to see how were the money used and more importantly what you've learned about the users and the product ? A/B testing tools can help you measure things like conversion rate, churn rate, bounce rate and many others. They can help you learn from your experiments.They also allow you to make better usage of your time and money in the future.

Use UI A/B testing tools which don't require development

There are some specialized A/B testing tools which allow customization of the User Interface without the need to have a development team behind to do the changes. They allow Product Managers, Design teams to play around with UI functionality. They can easily modify size of fonts, colors, placing of UI elements and many others.
I've once heard a story at a tech event about www.hotels.com who were able to get a huge win in profits by increasing the size of the font used for displaying the price per room.

Use tools to monitor technical improvements and technical debt

Software teams are frequently in the situations of having difficulties to prove with data the value in implementing technical improvements or reducing technical debt or doing refactoring. Even if they get the approval and do it, they have even harder times in demoing the improvements made. Given this situation there is no surprise that in the majority of cases there will be features, change requests which will take priority over software team suggestions. As you might expect in some cases this will lead to big problems, and instead of being proactive we end up being reactive.
Software teams might have a better chance of motivating their suggestions if they could find a way to easily report the current problems and somehow show how suggestions will improve things. One way of doing that is using and showing reports and trends with: static code analyzers tools, code coverage tools, monitoring tools, areas with frequent bugs and so on.
What if when proposing a refactoring you would be able to provide a report which would include something like: module average score is 6 (given by a static code analyzer), average number of bugs raised on this module was 10% higher than on the rest of the modules, that this module was affected weekly, that the number of Sentry errors raised increased on this module with 5%? In the same time after refactoring was done, you could show off that average score on this module has increased to 7, average number of bugs raised in this module dropped with 10%, sentry errors from this module dropped with 15%. And nothing stops me to mix that with other metrics and measures defined.

Create your own prototyping software team

Do you want to move faster and test faster your ideas? Why not implement a prototyping software team (if possible)? which would be responsible to prototype ideas, new features and quickly validate them. The validation will imply A/B testing, measures done so that they can decide if it should be part of product and be given to software team to properly implement them.

Implement a continuous delivery, continuous deployment strategy

Being able to test ideas faster will automatically imply you are able to deliver and deploy faster, maybe even multiple times in the same day. One way to achieve that is by using a continuous delivery, continuos deployment strategy. This will imply changes in how you do development, testing and deployment.

Use an agile process

All the above recommendations need to be governed in my opinion by an Agile process. Depending on your situation it can be Scrum, Kanban. You might also be already in "Ri" stage as Martin Fowler described in the stages for learning a technique or methodology and develop your own Agile process if you already mastered stages Shu and Ha.

On what kind of products could you use this method and practices?

• startups which already have some users - because they need more than everybody a way to learn if they are on the right path or they need to adapt.
• products which already have a huge number of users and maybe they are market leaders - you need to keep and increase your existing users, taking into account the number of options they have and new products coming in.
• internal products used in the company - even if you don't have to increase your number of users, you still need to improve their satisfaction, experience with the product and make their life easier.

Conclusion

In a world with a dynamic environment where technology plays an important part, we are put in a situation of making complex decisions more often. We have to start doing things differently if we want to adapt. We need the shortcuts, but we also need to help our brain to use them wisely. I strongly believe that the way to go in technology is to make decisions based on intuition and data.

Start small and define a reduced and high-impact measurements which could help you straightaway. After you understood how to use the data and how it can help you, you will be in a position to refine them or add more.

Recommended further reading

• read more on The Lean Startup Methodology in Eric Reis book. High-level overview of principles can be found on here
• read more about continuous delivery and continuous deployment in Jezz Humble and David Farley book and on continuousdelivery.com
• implement your agile process by using the guidelines provided in these books: Succeeding with Agile: Software Development Using Scrum, Kanban
• read more about UI A/B testing tools here